System and method for improving reliability of distributed electronic transactions

ABSTRACT

A system and method are disclosed that separate control functionality from the management functionality for conducting electronic transactions. The control functions are performed by a third party resulting in a low overhead since significant overhead is incurred in response to an anomalous event, thus facilitating high throughput electronic transactions when anomalous events are infrequent. Further, the third party does not need to have access to confidential information since it only controls by observing, validating and certifying the observed communications in a specified manner to prevent confidential information from leaving the context of the transaction. Management of the transactions based on consideration of substantive information is provided by the participants. A preferred system of the invention comprises a validation authority, a logical boundary at which validation authority undertakes control of communications, and validation rules specifying parameters for observation and the nature of comparisons.

REFERENCE TO RELATED APPLICATIONS

This is a continuation application of U.S. application Ser. No.10/882,155, filed Jun. 30, 2004, the content of which is incorporatedherein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to the field of electronicbusiness transactions, and in particular to methods and systems forproviding secure, reliable and efficient distributed electronic businesstransactions.

BACKGROUND OF THE INVENTION

Fueled by the growth of Internet, more and more private, commercial andgovernmental organizations strive to interact, conduct business, andprovide various services electronically that go beyond merely providingaccess to information. Individuals share files through e-mails, personalwebsites and exchange information in online chat rooms. Small and largebusiness provide plethora of online services including virtual retailand wholesale stores, personal electronic banking and investmentservices, online reservation services, etc. Government agencies alsoutilize widespread public access to Internet to provide such onlineservices as renewal of driver licenses, electronic filing of taxes andeven patent applications. Thus, the Internet has become more than just apipeline for sending data, it has become a medium for conductingelectronic transactions that promise speed and high throughput.

As the frequency and complexity of online business transactions grow,the task of assuring the security and reliability of such transactionsbecomes increasingly difficult. High throughput or speed often resultsin reduced security and even security breaches. For instance, a typicalonline purchase transaction may involve a buyer requesting purchase ofparticular goods; a seller checking availability of the goods; the buyertransmitting billing information to the seller; the seller billingbuyer's credit card or bank account; the seller requesting shipment ofgoods from a delivery service, and finally shipping the goods. If thisprocess is required to be speeded up, then it is imperative that thebuyer provide confidential information over the Internet to the selleror alternatively the seller limit sales to alternatively authenticatedbuyers, such as existing customers, or offer goods under control ofanother Web retailing site such as Amazon.com and the like. The sellercould also ship goods or provide access to services on little more thana prayer and a hope. In the event there is a dispute, there is no clearmethod for determining the nature of the transaction other the recordsof each of the parties themselves.

Moreover, due to significant back-end processing conducted by each partyin the course of a complex electronic transaction, a virus or a hackerattack or a failure of an application, system or network may disrupt anypart of the transaction with the result that one or more parties may beunsure of their rights and remedies or the status of the transaction.Faced with such a disruption, there is no clear method for determiningthe nature of the disruption and its effect on the transaction otherthan the records of the parties themselves.

To mitigate these problems, parties to the electronic businesstransaction sometimes rely on trusted-third-party services. Usually sucha service includes one or more of certification of a transaction,authentication of the parties, distribution of dataencryption/decryption algorithms, distribution of secret information,recording of the transaction details and arbitration of disputes betweenthe parties concerning the authenticity of the communication. There aredrawbacks to the use of such third parties since, for example, therecording of the transaction details by the third party results in thethird party having access to confidential information as well. Inaddition, the need to record and respond to voluminous informationrequires significant investment in infrastructure, such as server banks,and bandwidth on part of the participants and the third parties. As aresult, the choice of suitable third parties worthy of such trust israther limited with the risk of future conflicts of interest while beingaccompanied by significant performance and cost penalties.

There are some patents describing the use of such third parties. Forinstance, in U.S. Pat. Nos. 5,790,677 and 6,560,581, a trusted thirdparty is used as a credential binding authority to register parties to atransaction and then to authenticate them using their registrationinformation when a transaction is initiated. Thus, the credentialingparty is privy to the otherwise confidential information about all ofthe parties in the subsequent transaction.

Moreover, the parties subsequently exchange commercial documents andinformation but with little recourse if any particular communicationfails. Thus, if an offer was made then the party making the offer maynot know whether a delay in receiving an acceptance is due to a networkproblem or due to a rejection of the offer.

In U.S. Pat. No. 6,199,052, a trusted third party acts as anintermediary and a non-repudiation authority that prevents either partyto a transaction from denying receiving a message that has actually beenreceived. In U.S. Pat. No. 6,327,656, a trusted third party certifiese-mail transmissions for subsequent verification and authentication. Inboth of these patents, the trusted third party has a significant amountof information about the transacting parties. Further, in the event of asuspected breach it is not clear if the breach has actually happened.For instance, the problem of knowing whether a message has actuallyreached a party or a network failure has taken place may prevent one ormore parties from acting in a timely manner. While this may not be aserious drawback in the context of low throughput transactions, in ahigh throughput transaction context this could be a serious and costlyimpediment.

Further, the prior art third parties could themselves be commercialentities that if provided access to confidential commercial informationmay present a security risk that is only heightened if they are alsostoring or archiving such information. The concern with the unfetteredaccess to credit card and identifying information due to the bankruptcyof many web-based companies is another example of the danger posed bythird parties having too much information. Yet another example is thearchiving of text messages by text messaging service providers due tothe possibility of contested bills despite the security risk posed bysuch a cache, which may be a target for unauthorized or unexpectedaccess for reasons unrelated to establishing a transaction. Moreover,such an abundance of information may further load the networks, reduceefficiency and may reduce the possible throughput rate for electronictransactions that may require additional investment in resources toprovide a required transaction handling capacity. Thus, asking far toomuch or too little of third parties or trusted intermediaries presentsadditional problems.

Although prior art apparatus and methods address some security aspectsof electronic transactions, such as privacy, authentication and accesscontrol, they are still unreliable when an anomaly in the expected flowof electronic transaction occurs. Specifically, none of the abovemethods or systems adequately enable the trusted third party to resolveissues that might arise due to a disrupted transaction due to the lackof technical means to timely detect and act on the knowledge of suchdisruptions. For instance, in the case of certified e-mail, if an e-mailreached its destination but a certificate of the transmission has beenlost for one of the above reasons, the sender will be inclined toretransmit the e-mail assuming it never reached its destination.Depending on the circumstances, such retransmission may have unintended,and sometimes disastrous, results: if, for example, the original e-mailwas directed to a stock broker with a request to purchase certain numberof share of stock, and it was received and request was processed, thesecond e-mail making the same request may result in unintended purchaseof additional shares of stock. Accordingly, the prior arttrusted-third-party solutions, such as e-mail certification, areunreliable because they leave one or more parties guessing as to thecause of a disruption rather than flagging a disruption to allow a rapidresponse the transacting parties.

SUMMARY OF THE INVENTION

The present invention improves reliability of electronic businessprocesses by means of a third party capable of effectively detecting andnotifying transacting parties of an anomaly in the expected flow ofelectronic transactions. The third party requires a low overhead, muchof which is incurred when an anomaly occurs, thus making the system andmethod in accordance with the invention suitable for high throughputelectronic transactions. Further, the third party does not need to haveaccess to confidential information.

Commercial transactions typically require both control and management.Control as used herein refers to the ability to affect the flow oftransactions in a content neutral manner while management of atransaction refers to the ability to modulate the flow of transactionsand the initiation or termination of transactions based on the content.Thus management, as used herein, requires knowledge of the materialterms and conditions in transactions. A party managing a transaction mayrespond to a particular interruption in electronic communications byentering into a different contract or negotiations and the like.However, a party controlling an electronic transaction only observes,validates and certifies various combinations of electroniccommunications without requiring knowledge of the underlying details.This separation of functions is useful in setting up high throughputelectronic transactions and distributed computing.

A system in accordance with the invention may comprise: (i)participants; (ii) one or more third parties acting as a validationauthority; (iii) a logical boundary at which control of communicationsis undertaken by the validation authority; (iv) validation rulesspecifying parameters for observation, validation and certification; and(v) service pairs organized into business processes such that theservice pairs exhibit at least a partial order. The last two componentsmay be specified by way of one or more agreements that allow and specifythe nature of information to be observed in order for the validationauthority to perform its control functions for executing a businessprocess.

Thus, in the context of the present invention, a control process mayrequire as little as validating an electronic communication bydetermining that the electronic communication as sent by one party wasreceived by a second party in an uncorrupted state. Further, avalidation report may validate a request/response pair forming a servicepair by combining validation of an underlying request communication anda response to the request communication. In accordance with theinvention, a validation report is not required for each service pair.Instead, a validation report is used as an event or an indicator, whichmay be used to direct additional transactions. Further, a businessprocess comprising several service pairs may be certified based ondetecting whether a required partial order of service pairs was actuallyobserved and underlying validation reports. Accordingly, in the broadestsense, control includes observing, validating and/or certifyingelectronic communications.

Significantly, control, as used herein, does not include managing anelectronic transaction by actually accessing or acting upon the detailsin an observed communication, which details may well be keptconfidential. While in some embodiments of the invention, the same partymay perform some control as well as some management functions, thechosen description allows the description and implementation of anefficient control function that does not compromise the confidentialityor security of the observed communications. Thus, in a high throughputelectronic transaction environment, such an arrangement allowsvalidation of many transactions without raising security concerns.Further, the validation authority is then a third party that does notrequire the degree of trust required by the prior art since it istypically not trusted with highly confidential information. In a relatedaspect, the validation report may be provided or its existence confirmedas required in substantially real time due to the low overhead resultingfrom the separation between the control and management functions. Thevalidation authority only needs to be trustworthy for the purpose of thecontemplated electronic transactions since it need not serve as arepository of confidential information. This factor alone makes the taskof managing a business process easier with only the control functiontransferred to a third party acting as a validation authority.

In a preferred embodiment, the validation authority validates acommunication by detecting a plurality of specified parameters. Anindicator based on the observed communication at a sender is thencompared to a similar indicator based on the state of the communicationat the receiver end. The term ‘state’ here does not necessarily requirea knowledge of all possible parameters, but rather reflects an imperfectknowledge based on the information required to generate indicators.Thus, a state of a communication may include noting whether a particularfield is present and whether the value for that field is a specifiedvalue. Such a definition allows one to ascertain, e.g., whether a partyhas been successfully authenticated from the response (to a request forauthentication) indicating ‘SUCCESS.’

Then validation typically requires determining that two indicators areidentical, or as expected, thus providing evidence that the sentcommunication is the same as the received communication. Advantageously,the generation of indicators may be performed by deploying softwareagents that may send a hash based on the observed communication as anindicator of the observed communication to a validation authority. Ahash, or similar strategy, maintains the confidentiality of thecommunications, reduces the amount of information to be transmitted tothe validation authority, and allows automation of the control functionto efficiently handle electronic communications while maintaining highthroughput. Notably such an indicator may further include only someportions of the underlying communications. It may also includeadditional parameters that are not a part of the communication.

In another aspect, the use of specific rules under agreementscontrolling the validation authority, and the transacting parties allowscustomization of the control function for particular contexts. Forinstance, in a highly security sensitive environment, it may beimportant to not allow the use of proxy servers and instead specify thatthe sender and receiver of communications be directly connected. Theobservation of the sender's address in a communication and itscomparison to the sender in the message as received, which may bedifferent due to the use of a proxy server in the communication, flagsthe use of a proxy server.

The validation authority merely flags that the sent and receivedcommunications are not in the same state. The participants decidewhether to manage the transactions by terminating or otherwisesequestering contacts over such a suspicious communication link. Thus,the validation authority need not even know the significance of itsflagging such communications. It should be noted that such an event maynot even be flagged by the validation authority if the underlyingagreement did authorize observation, directly or indirectly via a hashetc., of parameters that included the sender's or receiver's IPaddresses. Thus, the participants have complete control by way of theiragreements with each other and the validation authority to ensure thatevents of interest are flagged and reflected in validation reports orcertificates.

In another aspect, the method of the invention includes generation of acertificate in the process of certifying a business process. A businessprocess is conveniently understood to comprise a plurality of servicepairs such that execution of a service pair may be a condition precedentfor carrying out another service pair. Thus, the existence of avalidation report based on the first service pair may satisfy thecondition precedent for carrying out the second service pair.

In another aspect, a business process may not require the transactingparties to be the same for each of the service pairs. Thus, if a firstservice pair comprises authentication of a first party with a secondparty, a second service pair may be a transaction between the first anda third party. Further, the plurality of service pairs in the businessprocess are required to be executed in accordance with at least apartial order. The partial order merely specifies that, for example, thefirst service pair is required to be executed prior to the execution ofthe second service pair. Then, the execution of the second service pairmay be in response to detecting a validation report corresponding to theexecution of the first service pair. This allows, in the example,preexisting agreements between the second and third parties to establishtrust relationships that are local to them without requiring exchange ofthe first party's confidential information between the second and thethird parties.

Certifying a business process may include generating a certificateindicating a result of determining whether the plurality of servicepairs were executed in accordance with the partial order oralternatively, whether the plurality of service pairs were not executedin accordance with the partial order.

In another aspect of the invention, a software agent may be placed at alogical boundary, that itself may be specified by an agreement. Thevalidation authority is responsible for control of communications onlybeyond this logical boundary, while the transacting party is responsiblefor the control of communications on the other side of the logicalboundary. Without limitation such a logical boundary may be specifiedby, for example, one of a time point, completion of a specified servicepair, a firewall, and a request for initiating the observation,validation, and certification of communications by a party to thetransaction. It should be noted that a firewall is a logical entityrather than being exclusively understood to be a physical device.

In another aspect, an indicator of the state of an observedcommunication is received from a sender software agent or a receiversoftware agent. These software agents only extract the allowedinformation, i.e., corresponding to the specified parameters. Thesoftware agents may further process the extracted information togenerate a hash, and/or encrypt it prior to sending it to the validationauthority. The known methods for sending documents securely with the useof digital signatures and hashes may be used to perform this step. Suchuse of software agents reduces the amount of information actually sentto the validation authority. Further, it ensures that confidentialinformation does not leave the context of the transaction.

Suitable specification of validation rules allows dispute resolutionprocedures to be built into electronic transactions by providing thereports and certificates of the validation authority to adjudicatedisputes or remove uncertainty that may arise if there is a disruptionin electronic communications. Thus, some validation rules may includeprovisions for acting in the event a particular validation report is notavailable at a specified time point. A party may then be relieved of apossible liability by clarifying to all parties the agreed upon conductin such scenarios. Importantly, the required reports/certificates arenot only received in substantially real time or at about prescribed timepoints, but the communications between the transacting parties areassured to be reliable without having the validation authority act as agateway or a firewall that actually manages what data gets through.

In another aspect, a system suitable for automated implementation of abusiness process subject to such agreements between two or more partiesin accordance with the invention may comprise: business process means,validation means, validation rules, and a logical boundary forexercising control.

Business process means may include a direct or indirect specification ofthe service pairs forming the business process with the required partialorder for execution of the service pairs. These means may include, forexample, in computer executable form, provisions in an underlyingagreement specifying the service pairs for observation. Thus, codecausing a server or client device to request observation of a servicepair and check whether it is allowed to execute to ensure compliancewith a partial order would be a possible implementation of businessprocess means.

Validation means are authorized to observe communications relating toone or more service pairs by collecting predefined information to definea state of an observed communication. Examples of validation means mayinclude software agents for validation authorities that may be deployedto observe the communications as specified. They may further includecommunication links to a party in an electronic transaction and even avalidation authority depending on their configuration. Typically,validation means are capable of implementing validation rules, andpossibly generation of validation reports and certificates.

Validation rules specify parameters to be observed for validating theobserved communication by a suitable comparison. Typically, a validationrule may include a specification of syntactical components andstructural components in specifying the parameters for observation. Theparameters for observation are chosen such that they are sufficient forconfirming whether an error or another condition of interest exists.However, since the contents of a communication are typically notrecorded, a hash of such contents may represent the contents whenapplying validation rules.

Alternative validation rules may specify that only an authenticated usermay access specified information. For such rules, the observation ofparameters attesting to either successful authentication of a user orthe presence of authenticating information in a request may be allowedwithout access to the confidential authenticating information itself,thereby solving possible privacy problems. In the absence of theconfidential authenticating information, it is not possible to misuse itanother transaction. A comparison between a state of a communicationsent by a party and the state of the corresponding communicationreceived by the target party, ensures that the transmission was errorfree without requiring access to the information contained in thecommunication itself. Indeed, a possible validation rule may requirecomparing two fields in a single received communication to ensure thatit is genuine.

The validation means may further assist in synchronizing execution ofseveral service requests. Upon a request for a service or businessprocess by a first party, one or more parties capable and willing toparticipate may respond by requesting a specification of a suitablelogical boundary. Validation means may then respond to such requests byselecting the required number of parties based on one or more ofrelative timing of the requests, available resources, and a preferenceof a party. Further, the parties whose requests were not honored arefree to compete for executing other service pairs. Generation of asuitable validation report by the validation means may inform them ofthe result of a particular selection.

The system may further comprise a system interface that would include aspecification of protocols to ensure that the various components canwork together. This may include, without limitation, implementing XML orSOAP based communications between the participants and the validationauthorities so that the validation rules are implemented and reportsgenerated can be acted upon. Of course, any other presently known orfuture developed communication protocol suitable for that purpose can beused as well.

The invention is further described in detail below with the help of thefollowing illustrative figures.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will be described next with references to thefollowing drawings.

FIG. 1 schematically illustrates a communication network in which thepresent invention may operate;

FIG. 2 illustrates an exemplary embodiment of a cooperation agreementspecifying validation rules and the like.

FIG. 3 is flow chart illustrating operations conducted by the validationauthority in an embodiment of the invention.

FIG. 4 is a flow chart illustrating operations conducted by a party inan embodiment of the invention.

FIG. 5 is a flow chart illustrating in more detail operations conductedby the validation authority in an embodiment of the invention.

FIG. 6 is a flow chart illustrating the operation of the validationauthority when one of the parties to the transaction fails to respond.

FIG. 7 is a flow chart illustrating the operation of the validationauthority when one of its software agents fails to respond.

FIGS. 8 A though C schematically illustrate operation of the validationauthority in a distributed computing environment in accordance with anembodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In an aspect, the present invention improves security, reliability andefficiency of distributed electronic business processes by means of athird party that detects an anomaly or interruption in the expected flowof electronic communications. The third party provides controlfunctionality without having access to confidential information that isneeded for management functionality.

Electronic transactions involve at the lowest level a ‘communication’from one party to another party. Such communications may be organizedinto service pairs, each service pair comprising of a requestcommunication and a response thereto. This description is useful in aserver based environment where clients contact servers willing and ableto provide a desired service. At the next level, a plurality of servicepairs are organized into a business processes such that the plurality ofservice pairs exhibit at least a partial order.

Commercial electronic transactions typically require both control andmanagement. Control refers to the ability to affect the flow ofelectronic communications in a content neutral manner while managementof a transaction refers to the ability to modulate the flow oftransactions based on the content. Thus management of the transactionrequires knowledge of the content of the communications since it relatesto the material terms and conditions. In contrast, control would flagevents of interest based on detection of bottlenecks, failure of acommunication link, mismatch between addresses for electroniccommunications, whether a message was actually delivered or whether aresponse to a message was sent/received, or other similarconsiderations. A party managing a transaction may respond to aparticular interruption in electronic communications by entering into adifferent contract or negotiations and the like. However, a partycontrolling an electronic transaction only observes, validates andcertifies various combinations of electronic communications with littleknowledge of the underlying details. This separation of the managementand control functions is useful in that it allows a neutral third partyto establish facts in and automate dispute resolution by providinginformation limited to whether a message(s) or pre-defined part thereofwas delivered and the like.

A control functionality may be able to certify that a specificcommunication of interest actually took place. Since, control does notinclude managing an electronic transaction by actually accessing oracting upon the confidential details, this separation of control frommanagement allows implementation of an efficient control function thatdoes not compromise the confidentiality or security of the observedcommunications. Thus, in a high throughput electronic transactionenvironment, such an arrangement allows validation of many transactionswithout raising security concerns.

The separation of control from management is possible by specifyingsuitable validation rules that determine the parameters for observation,resulting in validation and certification of electronic communications.It is convenient to think of the third party as validating individualelectronic communications, issuing validation reports for some servicepairs, and issuing certificates for business processes in accordancewith the validation rules.

Another control function is in recognizing one of several serviceproviders for a service pair. If several servers can serve a particularuser request, they respond to the third party with a request toestablish a logical boundary for observation of electroniccommunications in servicing the user request. The third party thenselects one or more of them by sending them validation reportsindicating whether they are free to bid for serving another request.Thus, the validation reports may be used to synchronize execution ofservice pairs in a business process such that they are executed inaccordance with the specified partial order (checked by reference tovalidation reports) and to distribute execution of service pairs betweenservers to effect distributed computing with the third party operatingas a low overhead engine.

A business interaction may be conceptually separated into three phases:a registration phase, a transaction phase, and a certification phase.During the registration phase, each of the parties desiring toparticipate in a business process register with the third party actingas a validation authority. Registration may mean that the partiesaccept, for the agreed set of business processes, the validity of thesigned reports generated by the third party concerning execution of theservices and business processes.

The parties then further agree to cooperate for carrying out one or morebusiness processes, where an agreement may define a business process asa partially ordered set of service pairs. A service pair is a requestcombined with a response thereto The cooperation agreement furtherdefines various technical and organization parameters that enable thetrusted third party to monitor execution of the transactions. Inparticular, such parameters may include but are not limited to thecooperation rules, organizational procedures and the system interfacesof the registered parties.

During the transaction phase, the third party controls the execution ofthe business process to the extent of its allowed observation,validation and certification functions pursuant to the business processrules, which are a subset of cooperation rules. This monitoring ispreferably performed transparently by means of two parallel connectorsbetween each transacting party, which allows monitoring of the dataentering or leaving its source and destination points. This issufficient for the third party to provide transmission verification andnon-repudiation services without storing or otherwise being aware of thecontent of the communications themselves. This lack of awareness ofcontent refers to the fact that the third party only determines a statedefined by the parameters it is allowed to observe. It, typically, willnot have the authority to cache all of the significant information froma transactional perspective for managing the transaction. Instead, suchinformation may be used to generate a signature in the form of a hash orsimilar quantity as an indicator of the observations.

FIG. 1 provides an illustrative diagram of a system 100 suitable forimplementing a method in accordance with the invention. Participants 110and 120 communicate over network 130 and over a communication link thatincludes software agent 140 corresponding to logical boundary 145proximate to participant 110. Software agent 140 observes communicationsdirected to and sent by participant 110. Similarly, agent 150 issituated at logical boundary 155 close to transactional party 120.Agents 140 and 150 communicate with validation authority 135 over links160 and 170 respectively.

Illustrative FIG. 2 provides a flowchart of possible provisions in anexemplary agreement for implementing an embodiment of the invention.Although the illustrative agreement 200 has many provisions, otheragreements used in alternative embodiments of the invention may notinclude all of them. Agreement 200 includes provision 205 specifying apartial order for execution of service pairs in a business process. Sucha provision may typically bind the transacting parties, but may alsoapply to the validation authority. For example, the validation authoritymay be required to reveal the existence of a validation report inresponse to another event or service pair being executed.

Agreement 200 includes provision 210 specifying which third party orentity is to operate in the role of a validation authority. Theparticipants to a transaction are expected to agree to a commonvalidation authority for more effective and efficient processing ofelectronic transactions. Agreement 200 also includes provision 215specifying that the validation authority, for example, validationauthority 135 of FIG. 1, is authorized to observe the communicationsbetween the transaction parties. Such observation is subject to onlycollecting information that is specified in the agreement. Thus, anagreement may specify that the IP address of a sender is not to beobserved, but a status field in an XML encoded message is to be observedto detect a state, such as an input is acceptable or there are no errorsand the like.

Agreement 200 includes provision 220 specifying that the validationauthority is allowed to or even required/expected to detect the order ofexecution of service pairs as specified. Further, agreement 200 includesprovision 225 specifying that the validation authority is required togenerate validation reports for one or more service pairs. Thevalidation authority, pursuant to provision 230 in agreement 200, canconfirm the existence of a particular validation report. Suchconfirmation may indicate successful completion of a particular service,e.g., authentication of a particular party by a trusted or known party.Further, agreement 200 includes provision 235 specifying that thevalidation authority may certify a business process based on thevalidation reports of one or more services included in the certifiedbusiness process.

In another aspect, agreement 200 also includes a provision 240specifying of one or more interfaces to allow different entities tocommunicate with each other. Such interfaces may specify the format orother features significant for communication. Further, agreement 200includes provision 245 specifying organizational provisions that may berequired for proper transactions with the validation authority or eachother.

In an exemplary interaction with the validation authority, FIG. 3depicts some steps that may be carried out by a validation authority. Itshould be noted that not all embodiments of the invention require thatthese illustrative steps be carried out by the validation authority.During step 305, validation authority registers participants to anelectronic transaction. Control flows to step 310, in which therequisite agreements are entered into by the various parties. Then theregistered parties establish logical boundaries by requesting thevalidation authority to observe communications between the parties. Inturn, during step 315, the validation authority dispatches softwareagents to the registered parties for assisting in the observation of thecommunications. In one embodiment, a party initiating the transactionmay contact the validation authority to establish the boundaries (e.g.,using the AskFor™ functionality). The parties are responsible forcontrol on their side of the logical boundary while the validationauthority is responsible for the control functionality on its side ofthe logical boundary. The validation authority may also contact otherparties to confirm their acquiescence to the specified boundaries andthen dispatch software agents to all participating parties.

The electronic communications between the transacting parties areobserved during step 320 by the software agents, which send indicatorsto the validation authority to assist in the validation process. Next,in step 325, the observed service pairs are compared and then anyadditional validation rules applied during step 330. If the observationis acceptable and there is no disruption of the ability to observe,control flows from step 335 to step 340, whereby, in the normal courseof transaction, the presence and operation of the validation authorityis almost transparent and insubstantially intrusive. However, if theability to observe is adversely affected, then the method terminateswith control flowing from step 335 to step 345 and the certificate isgenerated in step 345.

During step 340, if a certificate is not required, i.e., the businessprocess has not terminated, control flows back to step 315 for settingup observation of a new service pair, if required. Otherwise, thecertificate is generated to inform the parties of the status of thebusiness method. Typically, if all of the service pairs have not beenexecuted, then the business process is not considered to be complete.However, in some scenarios, the required number of service pairs may notbe fixed a priori. Thus, the execution of the business process may bemanaged dynamically.

FIG. 4 illustrates steps conducted by one or more transacting partieswith respect to the validation authority in accordance with oneembodiment of the present invention. In step 405, one or more partieswho desire that their transactions be controlled by a validationauthority register with validation authority. In step 410, the partiessubscribe to an agreement with the validation authority. An exemplaryagreement was described above with reference to FIG. 2. Once one of theparties is ready to initiate a transaction, in step 415, it contacts,for instance using the AskFor™ functionality, the validation authorityto establish a logical boundary for the observation, validation, andcertification of communications between the transacting parties. Inturn, the validation authority may contact the other participatingparties to confirm their acquiescence to the specified boundary anddispatches software agents.

Next, the validation authority observes the communications between theparties in step 420. Once a service pair requiring a validation inaccordance with the validation rules is observed, the validationauthority issues validation reports. In step 425, the registered partiesreceive the validation report and decide whether or not to continue thetransaction during step 430. If the transaction is to be terminated, themethod terminates after step 430. If the received validation report isfavorable, for instance, indicating that the request and responsecommunication complied with the validation rules, the parties continuetheir communications until the next report is generated by thevalidation authority. In step 435, following validation of service pairsspecified in agreement, a certificate is received from the validationauthority describing the outcome of a business process. Pursuant to thiscertificate, in step 440, the party may determine whether or not toproceed with a next business process.

FIG. 5 describes in more detail operation of the validation authority inaccordance with one embodiment of the invention when no anomaly orinterruption occurs in the course of the transaction. Following steps505 and 510, in which participating parties register with the validationauthority and establish boundaries, the validation authority observescommunications between the registered parties. In steps 515 and 520, thevalidation authority receives indications of a sent request and areceived request from its software agents. In step 525, the validationauthority applies the validation rules for this specific businessprocess to ensure that the request is authorized. For an authorizedrequest, the validation authority awaits an indication of a response. Insteps 530 and 535, the validation authority receives indications of asent response and a received response from its software agents. In step540, the validation authority applies the validation rules to determinewhether the response is acceptable in accordance with the validationrules, e.g., whether it is authorized, or corresponds to the receivedrequest and the like. In step 545, the validation authority generatesreports to the registered parties validating the service pair. It shouldbe noted that there is little disruption due to the generation of thereport since it advantageously is in a default low overhead form. Forinstance, if the next service pair is requested then if everything isok, the update of the software agent is provided corresponding to asatisfactory validation. Otherwise, the validation authority generates avalidation report detailing or explaining the denial of the softwareagent update. This use of default responses further reduces the requiredoverhead for control functions. Finally, in step 550, the validationauthority issues a certificate to the parties on the outcome of thebusiness process.

FIG. 6 illustrates operation of the validation authority when one of theparties to the transaction fails to communicate in accordance with theagreement. Once the boundaries have been established and the softwareagents have been put in place, the validation authority receives in step605 from one of its software agents indication of a sent request and areceived request for a particular service. In step 610, the validationauthority applies the validation rules for this specific businessprocess to determine whether such a request is authorized by theparties. For authorized requests, the validation authority awaits anindication of a response in step 615. In step 620, the validationauthority checks for the expiration of a time limit for receiving aresponse. If such a time limit has expired, the validation authorityissues a report in step 625 to the registered parties that no responsewas generated. In step 630, the service request may be retransmitted apredetermined number of times and each time validation authority willissue a report if no response was generated. Finally, in step 635, thevalidation authority will issue a certificate to the registered partiesnotifying them that the request was not processed.

FIG. 7 illustrates operation of the validation authority when one of itssoftware agents is not responding either due to internal problem withthe software agent or network failure between the validation authorityand the software agent. In step 705, the validation authority receivesfrom one of its software agents indication of a sent request and areceived request. In step 710, the validation authority applies thevalidation rules for this specific business process. For an authorizedrequest, the validation authority awaits an indication of a response. Instep 715, the validation authority fails to receive an indication of aresponse. In step 720, the validation authority applies its validationrules and contacts, in step 725, the non-responsive software agent todetermine whether or not a response was sent. If, in step 730, thesoftware agent confirms that no response was actually sent, validationauthority sends reports notifying the registered parties that therequest was not processed. If, in step 735, the validation authoritycannot reach the non-responsive software agent, it generates reportsnotifying the registered parties that the status of the transaction isunknown and authenticity of any received response is unknown. Finally,the validation authority generates certificates in step 740 on theoutcome of the transaction, and may subsequently try to resolve theproblem.

In another embodiment of the invention, the validation authority mayassist in synchronizing execution of several service requests from aclient to several servers operating in a distributed computingenvironment. With reference to FIG. 8A, client 820 sends request 815 tovalidation authority 810 for software agent 860 and the setting up of alogical boundary for observing one or more service pairs. Client 820then contacts servers 830, 840 and 850 via links 835 to find out whichone, if any will be available for providing the requested service(s).This may in the form of a challenge to prove they have a suitablesoftware agent, and thus are ready.

FIG. 8B shows that upon receipt of a request from client 820 to servers830, 840 and 850 requiring a response comprising an identifiercorresponding to that of the software agent present at the client,servers 830 and 840 from servers 830, 840 and 850 send request 845 forreceiving the corresponding software agent to validation authority 810.Server 850 exercises the option of not responding to the challenge atall. FIG. 8B also illustrates that since validation authority 810responds to the request for the required software agent and a suitablelogical boundary by more servers than are required for providing therequested service by providing software agent 870 to selected server 840in response 855 so that it may provide the requested service to client820.

FIG. 8C shows that client 820 and server 840 communicate over links 885and 895 with software agents 860 and 870 in place to observe theircommunications at logical boundaries 865 and 875 respectively as shown.Preferably, only those server(s) that are to provide the requestedservice receive the software agent. The rest may be provided with adenial or may time out and respond to other requests for service pairs.Thus, the validation authority remains a passive entity engaging incontrol by observing, validating and certifying. It however, alsoprovides a method for synchronizing among and distributing the executionof service pairs to servers 830, 840 and 850 with reduced overhead bymerely electing the parties or communications to be subject to itscontrol. In effect, it facilitates control of communications anddistributed computing in a multi-server environment.

In another aspect, the cooperation agreement may specify order ofpreference for selecting between the servers 830, 840 and 850, or theselection may be based on first come first served (FIFO) strategy or onresources available are a particular server. Selected server(s) allowthe deployment of the software agent at the logical boundary to startthe communications with client 820. Validation authority chooses aserver to serve the client's request pursuant to the cooperationagreement. It also generates and sends validation reports to client 820and the chosen server(s) for which logical boundaries have beenestablished. Then, the transaction observed by validation authority 810may be initiated.

The cooperation agreement defines the services and the order relationswith suitable validation rules and validation report requirements. Thereis no need to specify the roles of the service providers and users butrather only the rules for assigning these roles are laid out. Thepartial order is dynamically mapped at run time on the real serviceproviders and on the users. Thus, in response to a user request for aservice, several service providers (servers) may respond with a requestto set up the logical boundary necessary for control by the validationauthority. The actual establishment or failure to do so indicates to theservers whether their offer was accepted. From the network perspectivethe request ended up being scheduled for execution in a resourcesensitive manner dynamically, i.e., distributed computing.

The following examples provide further illustrations of the invention:

In the first illustrative example, a user wishes to initiate a businessprocess to obtain access to the Internet via a network provider. Thisbusiness process may be described as a collection of the followingrequests and responses:

A user connects to a network provider (Verizon, Wayport, . . . )

The provider asks the user for a credit card number/payment and theservice duration (one day, two days, etc.)

The user sends the credit card number and the requested duration.

The network provider answers with a receipt.

The user can now connect to internet using the network connection forthe requested duration time.

Since the user wants to have a record of the transaction and have areceipt in the event there is a dispute, the user also pays, e.g., at alow flat rate, the Validation Authority for providing controlfunctionality in this transaction. The validation authority generatesvalidation reports, which are sent to the user. If everything is fine,i.e., no disputes and the like, nothing needs to be done. The validationreports are on the user PC as its own documentation of the services.Thus, for a low cost the user has availed of the services of a thirdparty, which also does not incur great expense in providing therequested service. No additional user action is required.

Since, the validation authority is not in charge of the servicemanagement it does not need to maintain large servers as is typical whenthe third party is playing the role of a service intermediary, forinstance to guarantee the required bandwidth, computational power, andthe like.

However, if there is a dispute or something goes wrong in the businessprocess, then proof of what happened may be desired. As an example, theuser may wish to have proof of having paid for a piece of merchandise orservice over the web. For a fee, the validation authority generates avalidation authority certificate containing the validation reports andthe related time stamps and signs it. This certificate may then beemployed by the user to prove that the requisite payment, in lieu of alost receipt, and/or demonstrate that other steps were indeed undertakenproperly.

Thus the user subscribes to a cooperation agreement with the ValidationAuthority that asks (AskFor™) to be observed when he starts thedescribed business process. Further, in response to a user demand acertificate of the business process is generated containing thevalidation reports signed by the Validation Authority, the timestampsand the like.

In the second example, the functionality of the present invention can beuse to improve security and reliability of various types of electronicmessaging systems. Often email service providers and mobile textmessaging providers temporarily store the transmitted emails and textmessages to resolve potential disputes arising from customerscomplaining about allegedly undelivered emails or text messages thatthey have not sent but are being billed for. Storing such an abundanceof information may reduce efficiency and require additional investmentin resources to provide a required transaction handling capacity.Furthermore, such storage is also a security risk since an unauthorizedthird party may obtain access to the stored messages.

Providers of messaging services often retain a copy of the message,particularly text messages, to allow them to prove that the service wasindeed used in the event of a later dispute. This repository is asecurity risk to the participants. The use of the system and method ofthe present invention enables the providers and users to delegate theresponsibility of observing and certifying message transmissions withoutrequiring retention or caching of messages themselves by the use of aValidation Authority. Thus, in the event of a dispute in which proof ofmessage transmission is needed, the service provider may obtain from theValidation Authority a certificate containing the validation reports andthe related time stamps to confirm that the message was in facttransmitted and observed at both ends. Similarly, a user of themessaging system can obtain such a certificate from the ValidationAuthority to assert it against a receiving party who denies the receiptof a communication. The signature of the message contents sent to thevalidation authority (which may be provided in the certificate)discourages tampering with the message contents.

In the third example, the method and system of the invention providegreater certainty and options to participants in the formation ofcontracts or tracking performance of a contract and the like. Forexample, a buyer wishing to obtain a hundred shares places an order witha broker via email. However, although the order message indicated thatthe offer to buy at the stated price must be accepted by a specifiedtime, the buyer is uncertain in the event there is no response. It isnot clear if the order message was actually received and rejected by thebroker or whether the acceptance of the offer is held up, or evenwhether the message was received by the broker.

Subscribing to the services of a validation authority in accordance withthe present invention removes this uncertainty due to the execution ofsuitable validation rule. For instance, if the broker receives theorder, the absence of a report of a failure of the broker to receive therequest indicates to the buyer that the order message reached thebroker. If the time limit set in the order message expires, thevalidation authority generates a report or certificate, the existence ofwhich indicates to the buyer that he/she may engage in anothertransaction and to the broker that the time for acting on the ordermessage is past. If the broker does respond within the time limit thenboth parties know that there was a response and the buyer is free totake the next step.

It should be noted that the validation authority may not know that therequest was to buy shares or that the broker declined or accepted theorder and the like. Such information is useful for managing thetransaction but is not required for the control function.

The fourth example illustrates the scheduling capabilities of the methodand system of the invention. For example, with N users and M serviceproviders (could be servers in a network), at least one validationauthority and suitable validation rules (in a cooperation agreement),the user requests are distributed between the M service providers with alow overhead. The N users obtain services from the M service providersbased on available resources and other factors of interest. Thus, aservice pair may start with a request from a user i to a serviceprovider j.

The cooperation agreement may includes provisions for specifying whetherthe next service pair will be provided by the same service provider j orby another service provider in accordance with some alternativepreference to implement business-on-demand.

The cooperation agreement may also provide for the validation reports toindicate whether a request for the next service pair will be sent by thesame user i or by another user. This version of validation rulesimplements a cooperative work model.

The validation authority may also send validation reports to the serviceprovider/user for the next step. In this example, the partial orderdrives a complex cooperative process with requests potentially beingserviced by available servers an din accordance with an order. Note thatin this case the structure of the partial order reflects the complexityof the business process.

The fifth example provides some implementation details in an embodimentof the invention. In this example, for observation and validation, weuse

as a request of the j^(th) pair of the i^(th) business process.

is the response for the j^(th) pair of the i^(th) business process.

For observation of each service pair, the communication protocols arepreferably disclosed. Some well-known example protocols include: http,telnet, imap, smtp, pop3, ftp and the like. The disclosure may includethe data flow structure employed. Example data flow structures includeHTML, XML, SOAP and the like.

At the level of service pairs to be observed, the data components to beobserved are specified. For example: in a WEB-based communication, aparty may directly select fields to be observed on the web interface(the screen) and assign a logical name to them.

For actual observation, a request to the validation authority (i)establishes a logical boundary for the observation, and (ii) requests asoftware agent to observe communications in accordance with the logicalboundary. The validation authority dispatches a specialized softwareagent compatible with the protocols and data flow structures in use forthe service pair. Further, the validation authority opens a session,generates (or take them from an archive of previously generated keys) apair of unique cryptographic asymmetric keys (public, private), calledrespectively K_(pu) and K_(pr), and a unique session identifier (S_ID).The software agents dispatched to each party are set to work with theK_(pu) and the S_ID value, preferably for the entire duration of theservice pair or even the business process. Thus, each registered partycan advantageously use S_ID to identify its session and match up thesoftware agents assigned to observe the communications.

The software agent is configured by the validation authority to observethe specified data components or fields. At run time, the dispatchedsoftware agent operates as follows:

First, the software agent, dispatched to each registered party,challenges to verify that both of the parties to the communication havesoftware agents with matching S_IDs. In the event, a party so challengeddoes not have the required software agent, it sends the receivedchallenge to the validation authority and receives from the correctsoftware agent, or if it fails to so obtain the software agent, it maynot respond to the challenge.

Second, the software agent extracts or notes the specified datacomponents in the communications being sent and received in the courseof its observation function.

Third, the software agent calculates a signature, also termed anindicator, for example, a hash, of the observed data components.

Fourth, the software agent sends the signatures, the logical namesassigned to the data components, and the S_ID to the validationauthority.

In response, the software agent receives from the validation authoritythe validation report of the service pair being observed containing: aunique identifier of the service pair and possibly time stamps.

The software agent also stores in a directory associated with thevalidation authority, a file ciphered using K_(pu). This file comprises:the signatures; the observed values; the logical names assigned to thedata components; the unique identifier of the pair; the time stamp; theS_ID. The file may be accessed both via the unique identifier of theservice pair and the S_ID.

Turning to validation, the default validation rules comprise, forexample, the validation rules that are always to be applied to eachservice pair. Some such example default validation rules are:

a) The Validation Reports of the previously executed service pairs inaccordance with the specified partial order in the business process musthave been generated. This validation rule is applied, for instance, whenestablishing a logical boundary for observations for a current servicepair.

b) The specified parameters for the service pair must have beenobserved. This validation rule is verified during the execution of aservice pair. In other words, if the specified parameters are not beingobserved then the validation of the service pair fails due to thedisruption of the required observation function.

Examples of additional validation rules, for each service pair,comprise:

a) The observations made by a software agent dispatched to the client oruser must be equal to the observations made by the correspondingsoftware agent dispatched to the other side. This rule may be applied atrun time.

b) The observations made by the software agent equal one or moreobservations stored in validation reports of corresponding previouslyexecuted service pairs. This rule may also be applied at run time.

At run time the validation authority operates as follows:

If a logical boundary and software agents are requested for a firstservice pair in a business process, the VA opens a session, provides apair of unique cryptographic asymmetric keys (public, private), calledrespectively K_(pu) and K_(pr), and a unique session identifier (S_ID).Then the validation authority sets up a directory identified by theopened session, stores in this directory the S_ID, K_(pu) and K_(pr),and sets up the software agent of both parties with K_(pu) and S_ID. Forthe duration of the business process, each registered party uses theS_ID to identify itself in the business process. The software agentdispatched to each registered party, uses challenges to verify that theother software agent has the same S_ID. As described previously, if achallenged party does not have the correct agent, it may obtain one fromthe validation authority.

The validation authority also preferably verifies for each of therequest and its corresponding response that the Validation Reports ofthe logically preceding service pairs were generated. The validationauthority may also verify that the software agents are sending theindications and the logical names of the observations for the servicepair.

The validation authority verifies that for each service pair, thecorresponding indicators match. Thus, a sent request and the receivedrequest are associated with matching indicators for avoiding beingflagged. The validation authority may also verify that for eachobservation of the communications, the indicator matches the indicatorfor a prior observation, e.g., which may be stored in a validationreport.

In the event one or more observations fails to comply with thevalidation rules, a message is generated by validation authority. Actingon the messages, possibly taking into account their content and contextis in the domain of management.

The validation report is generated if both the request and the responsein a service pair have been validated at run time. Alternatively, withan identifier of the service pair, a time stamp of the operations may begenerated followed by the generation of the Validation Report. Theidentifier of the service pair and the time stamp may be sent to thesoftware agent for use in encoding the local observations and storingthem locally, possibly as Validation Reports.

A certificate may be generated, for example, in response to generating avalidation report of the last service pair in a business method inaccordance with the partial order. A certificate may be signed by thevalidation authority and may be further used by the managementfunctionality. A certificate is generated by the validation authority byretrieving the unique identifiers stored in the Validation Reports ofthe business process in question.

Advantageously, if the validation authority does not need to archive allof the validation reports. It may instead, for instance, send a reportto the transaction parties.

The validation authority, uses the private keys K_(pr) to encode thevalidation reports and issue a signed certificate, preferably with allthe desired observed values. This typically will not allowreconstruction of the confidential contents of the messages since theymay be represented by a hash or such indicator.

The illustrative descriptions of the application of the principles ofthe present invention are intended to enable any person skilled in theart to make or use the disclosed invention. These descriptions aresusceptible to numerous modifications and alternative arrangements bythose skilled in the art. Such modifications and alternativearrangements are not intended to be outside the scope of the presentinvention. The appended claims are intended to cover such modificationsand arrangements. Thus, the present invention should not be limited tothe described illustrative embodiments but, instead, is to be accordedthe broadest scope consistent with the principles and novel featuresdisclosed herein and described in the claims presented next.

1. A method for controlling an electronic transaction comprising:observing an electronic communication by detecting a plurality ofspecified parameters; receiving a sender indicator and a receiverindicator based on the observed parameters in the electroniccommunication as sent by a sender and received by a receiverrespectively; validating the electronic communication by comparing thesender and receiver indicators, wherein validation comprises determiningwhether the electronic communication as sent by the sender and receivedby the receiver is in the same state; generating a validation reportbased on validation of each of a request and a corresponding responsecommunication, wherein the request and response communications form aservice pair; and certifying a business process comprising a pluralityof service pairs based on the validation report for at least one servicepair in the business process.